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DETAILED ACTION 



1. 



This action is responsive to the application filed 9/16/2006. 



Claims 1-17 have been submitted for examination. 



Claim Objections 



2. Claims 1-17 are objected to because of the following informalities: The numerals 
expressed within parentheses - e.g. (118) - are not required for a US Application claim language 
and would induce confusion if not removed. Appropriate correction is not required but highly 
recommended. 



Whoever invents or discovers any new and useful process, machine, manufacture, or composition of mailer, or any new 



and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. 

4. Claims 10-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed 
to non-statutory subject matter. 

The current focus of the Patent Office in regard to statutory inventions under 35 U.S.C. § 
101 for method claims and claims that recite a judicial exception (software) is that the claimed 
invention recite a practical application. The following link on the World Wide Web is the 
United States Patent And Trademark Office (USPTO) reference in terms of guidelines on a 
proper analysis on 35 U.S.C. §101 rejection. 
<http:/7www.usptQ.goyA¥ey 

Specifically, claim 10 recites means operating a JVM and establishing connection 
betweeen a M2M and a server, means configured to download, communicate by the application 
and set the parameters by the application. As construed from the Specifications, means for 



Claim Rejections - 35 USC § 101 



3. 



35 U.S.C. 101 reads as follows: 
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running a JVM and to establish connection are implemented in software (e.g. built upon J2ME 
and secure mechanism using MIDP); whereas the act to download is not taught as being 
performed via any form of hardware. The steps recited as "communicate with the server" and 
"set the parameters ..." are construed as done by a downloaded application. In all, the M2M 
module claim amounts to software functionality with absence of supporting HW, and is treated 
as mere 'Functional Descriptive Material' or listing of software per se. Claims 1 1-17 fail to 
remedy to the lack of hardware support as set forth in claim 10. 

According the 35 USC § 101, 'Functional Descriptive Material' (see 101 Guidelines, 
Annex IV, pg. 52-54) cannot be construed as belonging to any statutory category of subject 
matter, and further more, absent any hardware support no data transformation in order in order to 
yield real-world result consistent with a required tangible utility is deemed possible. Claims 10- 
17 are rejected for constituting what appears to be a non-statutory subject matter. 

Claim Rejections - 35 USC §103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

6. Claims 1-3, 6-11, 14-17 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Nokia Corp, "Product Guide for Nokia M2M Application Development Kit", copyright 2002, pp. 
1-15 (herein NokiaADK - provided in Applicants' IDS 9/14/06), in view of Nokia30, "Nokia 30 
GSM Connectivity Terminal User's guide for modem use", Copyright 2002, pp. 1-56 (herein 
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Nokia30) in view of Ims, USPN: 6,542,908 (herein Ims) and APA (Admitted Prior Art: 
Background: pg. 1). 

As per claim 1, NokiaADK discloses method of configuring parameters of an M2M 
(machine-to-machine) module, the method comprising establishing a connection between the 
M2M module and a server (Fig. 1 pg. 3), characterized by the method comprising: 

an application having an interface for configuring the M2M module (IDL, stub, ORB - ); 

communicating by the application for receiving configuration parameters (names - top 
pg. 13; parameters settings - sec 6 pg. 1 1 - Note: use of parameters to establish connection to the 
GW reads on receiving parameters); and 

setting the parameters of the M2M module by the application based on the received 
configuration parameters ( GSM WAP parameter settings - see above). 

NokiaADK does not explicitly disclose downloading the application to the M2M 
module, nor does NokiaADK explicitly disclose application configured to run on a JVM. 
NokiaADK discloses a kit configured for a Nokia 30 terminal (sec 2.2.2) with interfaces to a 
M2M gateway (Fig. 4 pg. 6), where a kit includes configurator SW (sec 6 pg. 1 1), an "evaluation 
module" that interfaces with tracing and SW downloading — downloading remote end SW into 
said evaluation module (sec 4.1.3 pg. 7), said evaluation module for controlling server end 
though the M2M gateway and the GSM connectivity Terminal (sec 7.1 pg. 1 1), including Corba 
messaging (sec 4.1 pg. 7); wherein the M2M interface offers open interface to developers for 
these to control terminal application (sec 4.1.1 pg. 7; customer's own applications - sec 7 pg. 
1 1); wherein the evaluation module SW written in source code can be ported for specific 
operating system (sec 4.2 pg. 8), and application for ORB are modules provided from 
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developer's choice (sec. 4.2.1 pg. 9), where requirement for the M2M gateway featured in the kit 
includes Java 2 edition (sec 5.2 pg. 10) to support the server/control aspect of the evaluation 
module (sec 7.1 pg. 12 top) and where ORB stubs and code are supported by a IDL compiler 
(Fig. 6, pg. 14). Consistent with NokiaADK's downloading of installation SW (NokiaADK: can 
be downloaded - Fig. 7 pg. 15) or of applications from external source (e.g. developer's code) 
into the "evaluation module" to control terminal end connectivity and ORB communication as 
set forth above, Nokia30 discloses download and install drivers or "Configurator Software" for 
the Nokia 30 software functionality (Nokia30: pg. 22; downloaded - pag. 45); whereas 
intertwining relation between Java code used in Corba-based applications or connectivity stubs 
as in NokiaADK is disclosed in Ims as a well-known concept, where a Java Virtual machine 
supports method calls of applets, RMI, proxy (Corba, applet, RMI, proxy - col. 2 lines 15-64). It 
would have been obvious for one of ordinary skill in the art to implement the M2M module in 
NokiaADK using control software via configuration software from download as taught in 
Nokia30, and that such application would be in a Java source form (Java Platform edition 2), to 
be compiled to handle Corba messaging and remote invocation as in the M2M gateway 
approach, and run in a JVM as taught in Ims, because source code has to be adapted for specific 
control functionality as seen fit by a external developer (as per NokiaADK and Nokia30), 
requiring download via a interface or via a NW site, and that applet/proxy written to associate 
Corba-based communication call/message require a JVM by virtue of well-known methodology 
- as in Ims — that associates Java with Corba middleware mode of operations. 

Nor does NokiaADK explicitly disclose communication using the application with a 
server to receive configuration parameters. 
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NokiaADK discloses Corba naming service lookup using SMS methodology for 
delivery based on message acknowledgment (sec 5.1 pg. 10) where WAP parameter settings are 
performed by a Configurator SW (sec 6 pg. 11) and where the server end (supported by the Java 
control application portion of the Emulation module - pg. 12, top) queries list of objects that are 
registered to the broker of the terminal, such that the M2M kit uses IDL (sec 9 pg. 13-14) to 
support embedded application development based on the SMS process initiated at the terminal 
applications (sec 7.3, pg. 12). Sending SMS to receive from a server through a GSM gateway to 
a M2M module is disclosed in APA (Specifications: pg. 1). Consistent with the lookup for data 
registration pertinent to the terminal end in response to messaging, Nokia30 discloses software 
for connectivity and messaging in terms of security services (Nokia30: additional services - pg. 
1 1) or hyperTerminal program to establish SIM card authentication via a remote link setting 
(Nokia30: pg. 17). Parameters receiving to establish proxy and needed bean application using 
passed parameters from a server is further disclosed in Ims (see Ims: Fig. 4-6). In view of the 
data sent from server in Corba method calls (see Nokia30: pg 49) and the Corba lookup service 
as in NokiaADK and the parameters passing in Ims, it would have been obvious for one of 
ordinary skill in the art to implement the connectivity between terminal applications at the M2M 
client end applications and the remote Corba entities so that terminal end profile data or 
registration data, or configuration parameters - as in APA - needed for the user connectivity or 
WAP applications are received from a server as taught in the SIM security remote authentication 
by Nokia30, in Corba's server in Ims, or by the ORB look up approach by NokiaADK, because 
a wireless platform implemented via a gateway within a Corba based messaging scheme, has to 
recourse to a service and lookup service (e.g. to retrieve configuration parameters) or a remote 
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parameter provision as in Ims, in order for a authorized and authenticated client end - as in APA 
- request to be properly secured prior to receiving further resources, or to develop client 
application (as in Ims) and also as shown in NokiaADK (sec 6 pg. 1 1). 

As per claim 2, NokiaADK discloses connection between the M2M module and the 
server is established through a M2M gateway (Figure 1 pg. 3) or over a TCP/IP connection. 

As per claim 3, NokiaADK discloses communicating with the server comprises: 
requesting configuration parameters from the server and receiving , in the application, the 
configuration parameters from the server (refer to rationale set forth in claim 1) 

As per claim 6, NokiaADK discloses application being downloaded (refer to claim 1 
rationale - see Nokia30: pg. 22, 45) to the M2M module over a cable (NokiaADK: sec 4.1.4, pg. 
8; D9 connector ... downloading - sec 4.1.1, 4.1.3 pg. 7; see Nokia30), over an infrared 
connection or over-the-air (OTA) 

As per claims 7-9, NokiaADK discloses the application programming interface being a 
Common Object Request Broker Architecture (CORBA) API; 

using the M2M module (110) for configuring parameters of a remote device based on 
the configuration parameters (refer to claim 3) received from the server. 

NokiaADK does not explicitly disclose communicating with the server by making a 
method call through the CORBA API 

However NokiaADK disclose corba messaging to instantiating functions via use of IDL 
(sec 7.3 pg. 12; stubs - Fig. 6), the Corba broker disclosed as discovering ORB remote objects 
(sec 7.2-> 7.4, pg. 13) with IDLs to control the terminal and construed as terminal application in 
terms method calls (sec 2.1 pg. 2) using a IDL compiler implemented via the verification of 
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ORB SW module (sec 4.2 pg. 8-9). Based on the use of Corba to effectuate proxy and 
generating remote calls via returned parameters from server (see Ims: Fig. 4-6) based on Ims, it 
would have been obvious for one of ordinary skill in the art to implement NokiaADK's mobile 
application framework for ORB-based with IDL compiler to effectuate method calls via a Corba 
broker, so that the compiler would uses IDL to effectuate method call of a Corba API as shown 
in Ims, because parameter passing from a broker can help a registered mobile client to establish 
the proper call leading to connectivity and obtaining of resources as set forth in NokiaADK, via 
use of middleware to support the resource-restraint aspect of mobile applications. 

As per claim 10, NokiaADK discloses M2M (machine-to-machine) module, 
comprising: means for: 

operating a Java virtual machine (refer to claim 1 rationale) and means for establishing 
a connection between the M2M module and a server , characterized by the M2M module being 
configured to: 

download an application having an application programming interface (API) for 
configuring the M2M module (refer to claim 1 rationale), the application being configured to run 
on a Java virtual machine (JVM - refer to claim 1); communicate with the server by the 
application for receiving configuration parameters; and set the parameters of the M2M module 
by the application based on the received configuration parameters; all of which having been 
addressed in claim 1, in view of Nokia30, Ims, and APA. 

As per claims 11, 14-17 refer to claims 3, 6-9 respectively. 
7. Claims 4-5, 12-13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Nokia 
Corp, "Product Guide for Nokia M2M Application Development Kit", copyright 2002, pp. 1-15 
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(herein NokiaADK), in view of Nokia30, "Nokia 30 GSM Connectivity Terminal User's guide 
for modem use", Copyright 2002, pp. 1-56 (herein Nokia30); Ims, USPN: 6,542,908 (herein 
Ims), and APA (Admitted Prior Art: Background: pg. 1); further in view of Le et al, 
USPubN:2003/0233465 (herein Le) 

As per claims 4-5, NokiaADK does not explicitly disclose application being a Java 2 
Micro Edition (J2ME.TM.) application; the application being a Java MIDlet or a Java IMlet. 

NokiaADK discloses mobile communication GSM and Java-platform (refer to claim 1 
in view of Ims's JVM) to implement the "evaluation software" that control end-to-end terminal 
communication SW and tracing functionality (sec 4.2 pg. 8; sec 4 pg. 6-7) where SW module to 
implement ORB or wrappers has limited storage capacity (sec 4.2.1 ->4.2.3 pg. 9). The mobile 
device/platform version for embedded Java application is disclosed as J2ME, and this is utilized 
in Le. Le discloses use of J2ME and its well-known support for MIDP profile (para 0008 - pg. 
1) pertinent to Java-enabled mobile application/computing to implement RMI and message 
processing via a web ORB server (Le: applet, EJB, midlet - para 0018-0027; MIDP - para 0028) 
handling applet, EJB components, Midlet for ORB clients using Corba, security infrastructure. It 
would have been obvious for one of ordinary skill in the art to implement the mobile M2M 
gateway and configuration aspect of the Evaluation software in NokiaADK so that this control 
software, in light of the SMS, and connectivity parameter settings set forth in use of Corba/ORB, 
so that the software is implemented as a J2ME application destined for capacity-restrained 
mobile devices as taught in NokiaADK, including application software expressed in MIDlet, 
because this would utilize less resources of the client mobile and would also support security 
compliancy based on the well-known MIDP as set forth in Le (e.g. para 0025, 0028, 0034), 
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based on the registration of client users via ORB look up services or authentication as taught in 
Nokia30. 

As per claims 12-13 refer to claims 4-5 respectively. 

Conclusion 

8. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (571) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Lewis Bullock can be reached on (571)272-3759. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571- 
272-3609. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be 
obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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